CSDV3017 · DEVOPS · SCHOOL OF COMPUTER SCIENCE, UPES

Build Processes, Test Automation & Manual vs Automated Deployment

Lecture 16 — exploring the software build cycle, writing effective test cases, deep diving into automation testing tools, and revisiting the IBM Case Study on continuous testing.

InstructorDr. Mohsin Furkh Dar

SessionWeek 6 · Mon, 13 Jul 2026

Time14:00 – 15:00

UnitUnit VI

I

II

III

IV

V

VI

VII

WHERE WE LEFT OFF

Recap & today's agenda

Lecture 15 · Done

Intro to Testing

Shift-Left testing: testing earlier in the cycle.
Verification (Dev) vs Validation (User).
White-box vs Black-box vs Gray-box.
The Testing Pyramid (Unit > Integration > E2E).

Lecture 16 · Today

Builds & Automation

The software build process (compilation to artifact).
How to write effective test cases.
Automation tools in-depth (Selenium, Cypress, JUnit).
Manual vs Automated deployment risks.
IBM Case Study: Testing at enterprise scale.

FROM CODE TO ARTIFACT

The Software Build Process

Source Code

→

Compile

→

Link/Resolve

→

Package

→

Artifact

What is a Build?

Transforming source into execution

A build is the process of converting human-readable source code into a standalone, executable artifact that can be deployed to a server. It includes fetching dependencies, compiling code, running static analysis, and packaging everything together (e.g., into a .jar or a Docker image).

Build Tools

The Automation Engines

Java: Maven, Gradle, Ant
JavaScript/Node: npm, Webpack, Vite
Python: pip, Poetry
C++: Make, CMake

TEST DESIGN

How to write a Test Case

Definition

What is a Test Case?

A specific set of conditions or variables under which a tester will determine whether an application satisfies requirements. Good test cases are deterministic: they have a clear setup, execution, and an unambiguous Pass/Fail expected outcome.

The AAA Pattern

Arrange, Act, Assert

Arrange: Set up the initial state (e.g., create a mock user in the DB).
Act: Execute the function or behavior being tested (e.g., call the login() function).
Assert: Verify the result matches the expectation (e.g., check if the user received a 200 OK token).

Test Case Anatomy

Standard Fields

Test ID: TC_LOGIN_01
Description: Verify login with valid credentials.
Pre-conditions: User must exist in the database.
Test Steps: 1. Enter email. 2. Enter password. 3. Click Login.
Expected Result: User is redirected to Dashboard.

UNIT TESTING (CODE)

The AAA Pattern in Code

A simple Java JUnit test demonstrating Arrange, Act, Assert.

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class CalculatorTest {

  @Test
  public void testAddition() {
    // 1. Arrange - set up the test data
    Calculator calc = new Calculator();
    int a = 5;
    int b = 10;

    // 2. Act - execute the method being tested
    int result = calc.add(a, b);

    // 3. Assert - verify the output is correct
    assertEquals(15, result, "5 + 10 should equal 15");
  }
}

THE AUTOMATION ECOSYSTEM

Automation Testing Tools

Tool	Type / Target	Language / Characteristics
Selenium	UI / Web (E2E testing)	Supports Java, Python, C#. The industry standard for browser automation, but can be slow and flaky.
Cypress	UI / Web (Modern E2E)	JavaScript only. Runs directly in the browser, offering much faster execution and easier debugging than Selenium.
Appium	Mobile (iOS / Android)	Essentially Selenium for mobile apps. Supports native and hybrid mobile testing.
Postman / RestAssured	API / Integration testing	Tests RESTful APIs without UI overhead. Extremely fast and reliable.
JUnit / TestNG	Unit Testing (Java)	The foundation of the testing pyramid for Java applications.

THE FLAKINESS PROBLEM

Why UI Automation is difficult

"If you write 100 UI tests, you will spend more time fixing the tests than fixing the bugs they find." — The reason the Testing Pyramid exists

Problem 1

Timing Issues

The script clicks a button, but the page hasn't finished loading. The test fails (False Negative) even though the app works.

Problem 2

Selector Changes

The UI test looks for a button with ID #login-btn-blue. A developer renames it to #login-btn-new. The test breaks instantly.

Problem 3

State Management

E2E tests require complex database states. If Test B runs before Test A, it might delete the data Test A needs to run.

DEPLOYMENT RISKS

Manual vs Automated Deployment

Manual Deployment

The 2:00 AM Nightmare

Ops team SSHs into production servers.
Follows a 20-page Word document of runbook instructions.
Types commands by hand: git pull, npm install, pm2 restart.
Risk: Human error (typos). If a step is skipped, the system goes down. Rollbacks are entirely manual and chaotic.

Automated Deployment

The Push-Button Dream

Pipeline script handles the deployment (e.g., Jenkins, GitHub Actions).
Uses tools like Ansible or Terraform.
Risk: "Automated destruction." If a bad script is deployed, it can wipe out 100 servers just as fast as it can update them.
Mitigation: Requires strict automated testing and Canary/Blue-Green deployments.

CASE STUDY (CONT.)

IBM Case Study: Testing at Scale

The Challenge

IBM Cloud Kubernetes Service (IKS)

We saw in Lecture 13 that IBM moved from weekly, painful releases to multiple deployments per day using CI/CD. But how did they ensure quality when moving that fast? The answer was transforming their testing strategy.

Before DevOps

The QA Silo

Developers wrote code, threw it "over the wall" to QA.
QA performed manual regression testing for 3 days.
When bugs were found, developers had lost context of the code they wrote a week ago.

After DevOps

Shift-Left Automation

QA Engineers became "Automation Architects," building frameworks instead of clicking buttons.
Developers were required to write unit and integration tests alongside their features.
If the automated pipeline went Red (failed), fixing it became the team's #1 priority.

THE RESULTS

The ROI of IBM's Testing Shift

Minutes

Feedback Loop

Developers knew if their code broke the build within 15 minutes, not 3 days.

Scale

Microservices Testing

Using API (Gray-box) testing, they could automatically test contracts between hundreds of services.

Zero

Manual Deployments

Because tests were trusted, deployments to production became entirely script-driven.

The ultimate lesson: You cannot achieve Continuous Deployment without Continuous Testing. Test automation is the prerequisite for speed.

WRAP-UP

Summary & what's next

Lecture 16 · Key Takeaways

What you should remember

Build Process: Converting source code into an executable artifact via tools like Maven or npm.
Test Cases: Must follow the AAA pattern (Arrange, Act, Assert) for deterministic results.
Automation Tools: Selenium (UI, slow), Cypress (UI, fast), Postman (API, reliable), JUnit (Unit, foundational).
Deployments: Manual = human error risk. Automated = speed, but risks automated destruction without good tests.
IBM Case Study: Achieving high-velocity deployments required shifting testing left and empowering developers to own quality.

Next Lecture · Lecture 17

Mon, 13 Jul 2026 · 11:00–12:00 · Unit VII

Wait, the plan says Unit VII starts! Issue tracking tools: Bugzilla, GitLab Tracker, Jira; Types of bugs and classification.

Unit VI Complete ✓

You've finished Unit VI!

We've conquered Testing and Deployment. Unit VII will wrap up the course with Issue Tracking and emerging tech in DevOps.